As wireless network throughput capacity increases as well as the sophistication of mobile communications devices, Multimedia Messaging Service (MMS) type data transfers are becoming increasingly popular among users. However, current techniques for transferring such messages are not efficient and consume unnecessary network resources while also resulting in delays in both transferring and receiving an MMS.
With conventional systems, an MMS is typically sent from an originator network component to a server or relay associated therewith, which forwards the multimedia message to a server or relay associated with a recipient network component (or simply recipient). The recipient server then notifies the recipient about the MMS upon which the recipient retrieves the content from the server. The content retrieval and a read-reply are acknowledged by the recipient and returned to the originator server and eventually to the originator network node.
FIG. 1 provides a signaling diagram 100 which details the signals exchanged among an Originator MMS User Agent (UA) 110 of an originating terminal, an Originator MMS Relay/Server (or briefly Originator MMS Server) 120, a Recipient MMS Relay/Server (or briefly Recipient MMS Server) 130, and a Recipient MMS UA 140 of a recipient terminal with regard to the transfer of an MMS using conventional techniques. Via signal MA a request is issued to transfer an MMS from the Originator MMS UA 110 to the Originator MMS Server 130 (e.g., MM1_submit.REQ) which is replied to via signal 1B (e.g., MM1_submit.RES). Thereafter, the Originator MMS Server 120 forwards the request to the Recipient MMS Server 130 via signal 1C (e.g., MM4_forward.REQ), which is replied to by signal 1D (e.g., M4_forward.RES). The Recipient MMS Server 130 then notifies the Recipient MMS UA 140 about the request via signal 1E (e.g., MM1_notification.REQ) which is responded to by signal 1F (e.g., MM1_notification.RES).
If the Recipient MMS UA 140 chooses to accept the transfer of the MMS as provided in the request, signal 1G is generated and sent to the Recipient MMS Server 130 (e.g., MM1_retrieve.REQ) and a response is then sent back to the Recipient MMS UA 140 via signal 1H (e.g. MM1_retrieve.RES). With signal 1I, the Recipient MMS UA 140 then sends a content retrieval acknowledgment to the Recipient MMS Server 130 (e.g. MM1_acknowledgment.REQ), which then sends a signal 1J to the Originator MMS Server 120 reporting about the content (e.g., MM4_delivery_report.REQ) which is subsequently replied to via signal 1K (e.g., MM4_delivery_report.RES). The Originator MMS Server 120 then sends signal 1L to the Originator MMS UA 110 acknowledging the delivery report (e.g., MM1_delivery_report.REQ). The Recipient MMS UA 140 also sends a read reply acknowledgment via signal 1M (e.g., MM1_read_reply_recipient.REQ), which then sends a signal 1N to the Originator MMS Server 120 reporting about the content (e.g., MM4_delivery_report.REQ) which is subsequently replied to via signal 1K (e.g., MM4_delivery_report.RES). The Originator MMS Server 120 thereafter sends a read reply acknowledgment signal 1P (e.g., MM1_read_reply_originator.REQ) to the Originator MMS UA 110.
Notwithstanding the growing popularity of MMS, the amount of time required to deliver an MMS can be lengthy. One cause of delivery delays is shown in connection with the signaling diagram 200 of FIG. 2 which illustrates signaling among an originating network component such as an originating terminal 210, a Short Messaging Service Center 220 (SMS-C), a WAP Proxy 230, a Push Proxy Gateway 240 (PPG), and an originating Multimedia Messaging Center (MMC), i.e. an Originator MMS Relay/Server 250. The originating terminal 210 sends an MMS in signal 2A via WAP Proxy 230 and signal 2B to the originating MMC 250. With slow-speed network access, it can take up to forty (40) seconds until the MMS content is fully uploaded to the MMC 250. After the upload is finalized, the reception of the MMS is acknowledged by the originating MMC 250 via signals 2C and 2D. The originator MMC 250 then forwards the MMS to the recipient MMS Relay/Server (not shown) which also acknowledges the reception of the MMS.
FIG. 3 illustrates a signaling diagram 300 with similar components as FIG. 2, but in relation to the retrieval of an MMS by a recipient network component such as a recipient terminal 310. Via signal 3A a Push Access Protocol message is sent from an MMC, i.e., the Recipient MMS Relay/Server 350 associated with the recipient terminal 310 to a PPG 340, which acknowledges the message via signal 3B. A Short Message Peer-to-Peer protocol message 3C is sent from the PPG 340 to a SMS-C 320, which subsequently notifies the recipient terminal 310 of the MMS via signal 3D. The recipient terminal 310 may then send a notification to obtain the MMS in signal 3E via WAP Proxy 330 and signal 3F to the recipient MMC 350. The MMC 350 then downloads the MS to the recipient terminal via signals 3G and 3H. Similar to the uploading of the MMS to the originating MMC 250, the downloading of the MMS from the recipient MMC 350 to the recipient terminal 310 may also take up to forty (40) seconds depending on the speed of the network.
Accordingly, from the above, it will be recognized that the transfer of an MMS is accomplished substantially through three independent stages:                1. Originating network component to originator MMS Relay/Server;        2. Originator MMS Relay/Server to Recipient MMS Relay/Server; and        3. Recipient MMS Relay/Server to recipient network component.        
As such, the delivery of an MMS using conventional techniques is unnecessarily lengthy (especially if there is only a low-speed network access available) and results in the consumption of significant buffer space in the Originator and Recipient MMS Relay/Servers (which is based in part on the high number of parallel ongoing transmissions). Such delays can be compounded as the size of the MMS increases (e.g., in the case of large video clips).
The delays in receiving an MMS negatively affect user experience at a recipient network component and may discourage users from sending an MMS (and thus reduces potential throughput revenues to network operators). For example, in some cases, such as with regard to sports or news clips, a user may be eagerly waiting for the MMS to be fully loaded. In other cases, a user may know that an MMS is on the way, such as when the user is also participating in a voice session with the originating user and the MMS is sent in parallel (e.g., via combinational services, and the like), and that delay in delivery may negatively affect the interactions with other users. Delays are also problematic in multi-user group sessions in which a single user sends an MMS to all participants. As the receiving participants may have registered for the multi-user content, they are supposed to be ready for content reception.
Accordingly, there remains a need for an improved technique for delivering an MMS or a similar message from an originator to a recipient.